A smartcard or chipcard can be a tiny secure cryptoprocessor embedded within a credit card-sized card or within an even smaller card, like a SIM card for mobile phones. A smartcard usually does not contain a battery, but power is supplied by a card reader/writer, that is to say by a read and/or write device for controlling the functionality of the smartcard by reading data from the smartcard or by writing data into the smartcard.
A smartcard device is commonly used in the areas of finance, security access and transportation. Smartcards usually contain high-security processors that function as a secure storage means of data like cardholder data (for instance name, account numbers, number of collected loyalty points). Access to these data is only possible when the card is inserted into a read/write terminal.
It is a challenging task to enable integration of a user interface functionality directly into smartcards. For instance, a display may be integrated within a smartcard to display information to a user. Or, buttons may be included in the smart card to allow a user to enter data.
Smartcards were consciously designed without a man-machine interface providing user interaction capability. The lack of support for user interaction is reflected both in the hardware design and in the software design (operating system) of known smartcards.
This conscious choice has been driven by the lack of technology for thin, flexible displays and by strict security requirements posed for smartcards. Nowadays, since the technology for thin, flexible displays is available, strict security rules and procedures make the implementation of user interaction difficult. The introduction of API (application programming interface) known from consumer electronics devices and from personal computer devices is difficult, since security rules require that every system component has to be developed under observance of special procedures, for instance with respect to security and reliability. This requires, when developing or changing any chipcard processor component or software component, a lengthy certification procedure followed by a lengthy process of industry acceptance.
In the following, referring to FIG. 1, a smartcard with integrated display functionality according to the prior art will be described.
The smartcard 100 comprises a plastics substrate 101 on which an integrated circuit is formed, which provides the smartcard functionality.
In a security domain or processor 102 (a secure IC processor) of the smartcard 100, in which a high level of security is provided, a card manager unit 103 (which may be a logical unit, a software procedure running when an Application Protocol Data Unit, APDU, is received) is arranged which is adapted to communicate with a plurality of application units 104 each of which contains data and commands needed for servicing different applications. An operating system 105 is provided containing software for operating the smartcard 100. Further, a plurality of driver units 106 are provided, which are each used for driving an associated hardware unit 107.
The smartcard 100 is designed to communicate with a smartcard read and write terminal 108 as a master. The communication between the terminal 108 and the smartcard 100 is performed via the exchange of Application Protocol Data Units (APDU) according to ISO 7816. The card manager unit 103 exchanges APDUs with a particular one of the application units 104 to carry out a corresponding one of the applications.
The internal structure of the smartcard 100 is similar to a standard (personal computer-like) architecture, which can be described, in the well-known layered model. Looking at the hardware units 107, these units may include processors, memories, peripherals and several encryption/decryption co-processors working directly with low-level drivers. The driver units 106 form part of the Operating System Layer (OSL). OSL provides an abstraction of functions in hardware to applications and provides additional functions often reused by applications. The operating system 105 is also responsible for chip initialization during power-up.
On the top of the operating system, provider-specific applications may be run which are shown schematically in FIG. 1 as application units 104. Since smartcards like the smartcard 100 are commonly used with terminals like the smartcard read and write terminal 108, a master-slave like communication behaviour is deployed. This means that the terminal 108 initiates communication with the smartcard 100 sending Application Protocol Data Units (APDU) to the processor 102. The card manager 103 using address field in APDU may recognize to which application unit 104 it should be forwarded. Addressed application, after reception of that information, executes requested action and in return responds with status/data to the terminal 108. This communication scheme requires that for complex applications, both terminal 108 and smartcard 100 have to store actual state of communication.
Apart from the described components and their function, the smartcard 100 comprises extensions to allow a user interface functionality of the smartcard 100.
For this purpose, in a portion of the smartcard 100, which does not relate to the processor 102 (security domain), buttons 112 and a display 113 are provided. In order to allow a user to interact with the smartcard 100 via inputting commands by the buttons 112 and via outputting information on the display 113, there is a connection between the buttons 112/the display 113 and a button/display interface unit 111 arranged on the level of the hardware units 107. Further, a button/display driver unit 110 is provided on the level of the driver units 106 to allow a user to visually perceive data being displayed on the display 113. In the smartcard 100 shown in FIG. 1, a display functionality or user interface functionality is provided by the display 113 and the buttons 112. Furthermore, an extension or adaptation of the operating system 105 is necessary, which is shown schematically as an operating system extension 109 in FIG. 1.
While standard blocks of the smartcard 100 are shown with solid lines, additional blocks, which are necessary for input/output functionality, are marked with dotted lines. It can be seen that the button/display driver unit 110, the button/display interface unit 111, the buttons 112 and the display 113 as well as the operating system extension 109 have been added and the operating system 105 has been extended with functions to provide display functionality API to the applications performed according to the application units 104.
However, the smartcard 100 implementation according to FIG. 1 has some drawbacks.
Firstly, the operating system 105 requires modification in the form of the operating system extension 109. This causes development costs and certification costs. Moreover, due to the modifications interfering in the processor 102 (the secure domain) of the smartcard 100, potential security risks occur.
Secondly, apart from additions to the hardware drivers, an additional mode of use for the smartcard 100 has to be defined which differs from the native master-slave mode. This additional mode can be used when the smartcard 100 is started out-of-terminal (so-called “standalone mode”) to respond to a user pressing the buttons 112 and to display information. This affects the architecture of the smartcard 100 system and brings an additional security threat, which requires additional qualification.
Thirdly, the application units 104 need to be modified to incorporate an input/output functionality. This is difficult to achieve for well-known established and accepted standards like EMV (“Europay, Mastercard, VISA”, a standard for credit/debit financial card applications) or CEPS (“Common Electronic Purse Specification”, a standard for e-Purse Applications) and would require re-standardization.
Fourthly, the smartcard device (chip) requires to have additionally a hardware interface, namely the button/display interface 111, to communicate to the buttons 112/the display 113 and to the button/display driver 110, respectively. Such an interface may not be desired due to security threats.
JP 2001-331771 discloses an IC card with auto-display function, wherein a signal line for a communication between a reader/writer and a microcontroller is used in common as a signal line for transferring data to a display driver from the microcontroller. According to JP 2001-331771, an additional clock line (denoted as CLK2) is provided between display and secure microcontroller, which additional clock line is not led to the outer part. In other words, according to JP 2001-331771, the microcontroller controls the communication with the display. However, this has the disadvantage that security problems may occur when operating the IC card. Additionally, in JP 2001-331771, writing to the display is only possible when the card is in a read/write device.